When running unverified or untested third party code, infrastructure providers take protective steps to insulate or sandbox that code from potentially damaging the infrastructure or interfering with other applications running on the same platform.
When using web browsers, cookies are typically stored for websites that request data, such as state information, stored for future reference. This information in the cookie allows websites to persist in the browser, so that on return to the same website, for example, the user might not have to sign in again.
Cookie access permissions may be determined by the domain name portion of a URL, and pages served off of the same domain may be capable of accessing and modifying the same cookies. In contrast, pages served from a different domain may not have access to the cookies. Thus, for example, domain (domainX.com) properties such as DomainX Reader and DomainX Docs can be configured to have access to the same cookies and therefore share a common login experience, whereas, web pages served off of a different domain (domainY.com) will not be able to access these cookies (and vice versa). Maintaining this segregation of cookies helps to protect end user privacy and overall security.
Accordingly, third party code that can send a response back to the end user presents various potential problems such as, if the URL at which the code can be invoked is on a domain that has cookies. For example, a script may allow third party code to be run by visiting a URL on the script.domain.com domain and to produce output that is shown in the browser when the code has finished executing. In this way, an author of malicious code could construct a program that resulted in an output containing a script that would read or modify cookies from the domain.com domain
Several approaches are currently used to allow third party code to return results to a browser without compromising the security of the domain's cookies. In one approach, the code is restricted to “allowed” operations or outputs. For example, the code may be limited to specifically allowed strings such as “success” or “failure” that don't allow for the possibility of embedded scripts. Other approaches allow code results or outputs to show only as plain text, which disallows scripts (and potential threats), but also disallows any HTML formatting. Another, less restrictive platform, limits code results to JSON and RSS formats, and presumably validates the results to ensure that no untrusted script content can be embedded such that is may be executed. Yet another approach allows for structured code results that are interpreted and run as an AJAX web application, while preserving cookie security because it does not allow the code author to embed arbitrary scripts.
Another approach is to allow the executable code to produce results or effects that attempt to access domain resources (e.g. cookies), and redirect the end user's browser to a URL on a different domain that does not include any accessible domain resources (e.g. one with cookies to be read).
In the illustrated Prior Art embodiment of FIG. 1, redirection can be performed by having two servers 1010, 1030, one on a primary domain (Domain A) and one on a secondary domain (Domain B), both of which may be connected to the same backend storage system 1020. When a user device 1040 accesses a web page or URL on the primary domain (Domain A) that is set up to execute third party code, the result of that code is saved to the backend storage 1020 with a unique key or token (not shown). The primary domain (Domain A) then responds, not with the output of the executed code, but with a redirect 1050 (for example, an HTTP redirect such as an HTTP response with a status code in the 301 to 307 range) that references a new URL on the secondary domain (Domain B), and includes the unique key or token in the parameter string of the new URL. The browser on the user device 1040 automatically redirects to the new URL on the secondary domain (Domain B). In response, a first party program on the second domain (Domain B) looks up the unique key or token in the shared storage 1020 and produces the output from the original third party code. This output is then provided from the server at the second domain 1030 to the user device 1040. Once the content has been requested from the secondary domain (Domain B), it can be removed from the shared storage 1020.
As described above, a common solution is to temporarily store in storage 1020 the output of executed code, redirect the executed code to a server at a “safe” domain 1030, and have the “safe” domain serve the results from storage 1020. For example, with reference to the FIG. 1, when a user on a user device 1040 visits a URL in a browser, the user device is directed to a server 1010 at a primary domain (Domain A). The server 1010 at Domain A executes the third party code and produces an output. The output is stored in a storage 1020. The server 1010 at Domain A responds with a HTTP redirect 1050 to another server 1030 at a secondary domain (Domain B). Along with the redirect, a key or token is passed along to identify the output from storage 1020. The browser or application on the user device 1040 automatically redirects the output and key or token to the second server 1030 at Domain B. The server 1030 at Domain B uses the token to retrieve the output stored in the storage 1020, and presents the information back to the user device 1040 for display.
In the embodiment disclosed in FIG. 1, the server 1030 at Domain B is not stateless and must provide enough storage to hold all output that is pending waiting to be sent back to the browser at the user device. It is also imperative that the storage 1020 remain available between execution of the code and serving of the output. Additionally, and as described in the example, this system requires passing a unique key or token along with the redirect 1050 in order to identify which of the executed output in storage 1020 to return. Significantly, anyone with access to the key or token could have access to the output, thereby opening a third party to supply malicious code into the system.
In the case where executed third party code is to be served in a static manner, redirection may not be required. Instead, end users may be provided with a direct link to the secondary domain. However, in this scenario, the secondary domain does not have access to cookies from the primary domain, and thus no way to verify the end user that requested the original URL on the primary domain. The connection between execution of code on the primary domain and output from the secondary domain is therefore based on the unique key or token. In order to prevent users from seeing each other's output on the secondary domain that serves content based on the key or token, the key or token must be highly secure. This system also requires cooperation between servers on the primary and secondary domains, and is therefore vulnerable to the system on the first domain crashing (and potentially taking down the shared storage) between executing the third party code and serving it from the redirected URL. Moreover, the shared storage scenario can be problematic if the redirect request is lost (for example, if the end user closes the browser in between sending the initial request to the primary domain and receiving the redirected response).